This is an automatic backport of pull request #39855 done by Mergify.
Cherry-pick of a3758df has failed:

On branch mergify/bp/branch-3.2/pr-39855
Your branch is up to date with 'origin/branch-3.2'.

You are currently cherry-picking commit a3758dfd36.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   be/src/exec/pipeline/fragment_executor.cpp
	modified:   be/src/exec/pipeline/query_context.h
	modified:   docs/en/administration/query_profile_overview.md
	modified:   docs/en/reference/System_variable.md
	modified:   docs/zh/administration/query_profile_overview.md
	modified:   docs/zh/reference/System_variable.md
	modified:   fe/fe-core/src/main/java/com/starrocks/monitor/unit/TimeValue.java
	modified:   fe/fe-core/src/main/java/com/starrocks/qe/ConnectContext.java
	modified:   fe/fe-core/src/main/java/com/starrocks/qe/SessionVariable.java
	new file:   fe/fe-core/src/test/java/com/starrocks/monitor/TimeValueTest.java

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   fe/fe-core/src/main/java/com/starrocks/sql/analyzer/SetStmtAnalyzer.java
	both modified:   gensrc/thrift/InternalService.thrift

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

In the previous pr #33825, we've supported the profile only for big query with the session variable big_query_profile_second_threshold

Unfortunately, for some of our uses, most of the queries can be done within 200ms with a latency spike over 400ms, we cannot catch the slow query(400ms) with the session variable mentioned above.

What I'm doing & Behavior Change

• Remove session variable big_query_profile_second_threshold with type int.
• Add session variable big_query_profile_threshold with type string, it can support time duration like 1s/500ms/15m etc.

This change won't lead to compatible problem when performing grey upgrading.

• Only upgrade some of the backends, it works fine with the previous session variable big_query_profile_second_threshold.
• Only upgrade all of the backends, it works fine with the previous session variable big_query_profile_second_threshold
• And after upgrading the frontend, the user need to set up the big_query_profile_threshold corresponding to the previous configuration manually.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr